Process Manager Pattern

GPT-4.icon

複数のサービス／コンポーネントにまたがる長期的な業務フロー（ビジネスプロセス）を、中央の調整役である「Process Manager」が制御する設計パターンである。

主に分散システム、イベント駆動アーキテクチャ、マイクロサービスで用いられる。

概要イメージ

https://gyazo.com/d4e6fd416afbc5235f53cfc2d22c7eb4

何を解決するパターンか

1つの処理が複数サービスに分割されている

同期的な呼び出しだけでは破綻する（失敗・再試行・部分成功がある）

状態をまたいで進行管理（ステップ管理・分岐・補償処理）が必要

→ 各サービスに制御ロジックを散らさず、プロセス制御を一箇所に集約する。

基本構成

Process Manager

プロセス状態を保持（例：STEP1完了、STEP2待ち）

イベントを購読し、次のアクションを決定

コマンドを各サービスに送信

Services

単一責務の処理のみ実装

成功／失敗をイベントとして発行

Events / Commands

非同期で疎結合に連携

シンプルなフロー例

Saga（Orchestration型）＝ Process Manager Pattern

中央の制御役あり

Saga（Choreography型）

各サービスがイベントを見て自律的に進む

制御が分散し、可読性が下がりやすい

メリット

ビジネスフローが明示的・可視化しやすい

サービスがシンプルになる

リトライ・補償・分岐を集中管理できる

仕様変更に強い

デメリット / 注意点

Process Manager が肥大化しやすい

単一障害点になりうる（冗長化必須）

状態管理（永続化・再開）が難しい

過度に使うと「分散モノリス」化

実装時の設計ポイント

状態は必ず永続化（再実行可能に）

イベントは冪等に処理

タイムアウト／失敗時の補償フローを先に設計

プロセス単位で 1 Process Manager を基本とする

向いているケース

注文・決済・在庫など業務フローが明確

人手介入や待機を含む長時間処理

マイクロサービスでトランザクションを跨ぐ処理

向いていないケース

単純なCRUD

同期トランザクションで完結する処理

フローがほぼ存在しない処理